-
Notifications
You must be signed in to change notification settings - Fork 27
Replace manual config confirmations with automated cross-reference readiness check #38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
- New `export:supabase` command connects to Supabase Postgres and exports all users from auth.users including encrypted_password (bcrypt hashes) for password-preserving migration to Clerk - Auto-extracts display_name/first_name/name from raw_user_meta_data - Supabase transformer postTransform now extracts firstName/lastName from publicMetadata when not already set, so users don't need custom SQL to get names — the transformer handles it automatically Co-Authored-By: Claude Opus 4.6 <[email protected]>
|
Hey @jigar-clerk, I know you have a Supabase app with lots of users. Could you smoke test this PR real quick? Thanks! |
Scans the export data for raw_app_meta_data.providers to detect which OAuth providers (Google, Apple, GitHub, etc.) users signed up with. Displays a warning with user counts per provider and prompts to confirm the corresponding social connections are enabled in the Clerk Dashboard. Users who signed up via an OAuth provider that isn't enabled in Clerk won't be able to sign back in after their bridged session expires. Also adds raw_app_meta_data to the auto-export SQL query so provider data is included by default. Co-Authored-By: Claude Opus 4.6 <[email protected]>
…sers Replaces the user-data scanning approach with a direct fetch to the Supabase auth settings endpoint (GET /auth/v1/settings). This is authoritative — shows exactly which providers are configured at the project level rather than inferring from user records. Checks NEXT_PUBLIC_SUPABASE_URL + NEXT_PUBLIC_SUPABASE_ANON_KEY env vars (falls back to SUPABASE_URL, SUPABASE_ANON_KEY, or SUPABASE_SERVICE_ROLE_KEY). Gracefully skips if env vars aren't set. Co-Authored-By: Claude Opus 4.6 <[email protected]>
Tried it and out and works great, exported all of the users to json and was able to migrate the same users back into clerk |
…adiness check Instead of 5+ separate "have you configured X?" prompts, the CLI now automatically fetches both the Supabase auth config and Clerk instance config (via FAPI /v1/environment), cross-references them with user data, and displays a single unified readiness report. Users with disabled social providers are excluded from import. Co-Authored-By: Claude Opus 4.6 <[email protected]>
|
@jigar-clerk Mind testing this out once again? |
royanger
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you update the sample data for Supabase (samples/supabase.josn and samples/supabase.csv) with the OAuth related information and update/add tests for that? Or share a file or access to a test Supabase project with this info and can I can handle that separately?
I like the change to have one step showing the migration readiness. I think this could be tuned a little. Let me your thoughts on the below?
For example, with this PR I might get the following with no publishable key:
◇ Migration Readiness ────────────────────────────────────╮
│ │
│ Identifiers │
│ ○ Email — all users — enable in Clerk Dashboard │
│ │
├──────────────────────────────────────────────────────────╯
For something like this we can, and I think we should, provide directions like 'enable email in the Dashboard, and you can require it'. This will be counter to a situation where not all users have emails so requiring emails would cause those users to error on import.
The same applies for when there is a publishable key:
◇ Migration Readiness ──────────────────────────╮
│ │
│ Identifiers │
│ ✓ Email — enabled in Clerk — 59 users │
│ All settings are configured in Clerk │
│ │
├────────────────────────────────────────────────╯
| /** | ||
| * Displays a summary of the export results with field coverage stats. | ||
| */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Can we get the params and return info here for consistency?
Summary
/v1/environment), and actual user data#\d+discriminators from firstName/lastName in the Supabase transformer to prevent BAPI rejectionTest plan
bun test— all 152 migrate tests passbun run migratewithCLERK_PUBLISHABLE_KEYand Supabase env vars set — verify unified readiness report shows correct status per itemCLERK_PUBLISHABLE_KEY— verify graceful fallback to yellow "unknown" status#0discriminators in display names — verify names are cleaned🤖 Generated with Claude Code